package main

func main() {
	//log包很重要
	/*
		开发，debug,故障排查，数据分析，监控告警，保存现场
		我们需要设计一个优秀的日志包，如果我们要扩展就比较麻烦，1．基于zap封装，2．自己实现3．改zap的源码
		1．是否可以替换后期我们想要替换成另一个日志框架
		2．我们要考虑扩展性，log打印的时候是否支持打印当前的goroutine的id是否支持打印当前的context
		3．我们给大家提供的日志包，还能支持集成tracing(open-telemetry, metrics，logging),就可以集成jaeger
		4．是否每个日志打印都能知道这个日志是哪个请求的
		封装日志包很重要!最好是自己封装
	*/

	//gorm，go-redis、我们自己业务代码
	/*
				logger最基本的功能
					1．日志基本debug、 info、warn、error . fatal、panic
					2．打印方式2020-12-02T01:16:18+08:00 INF0 example.go:11 std log json (zap)
					3．日志是否支持轮转、单文件不能太大，压缩，切割
					4.日志包是否支持hook，gorm
				其他的需求:
					是否支持颜色显示是否兼容表中的Log
					error打印到error文件，info打印到info文件
					error能否发送到其他的监控软件，统计一个metrics错误指标error是否能支持发送到jaeger

			其他需求:
				高性能
				并发安全
				插件化:错误告警，发邮件 sentry
				参数控制

		 基于zap封装
	*/

	/*
		log使用经验：
			1. if分支的时候可以打印日志
			2. 写操作要尽量写日志 gorm，要记录数据
			3. for循环打印日志的时候要慎重，for+上万次
			4. 错误产生的原始位置打印日志 A(这里打印行不行)->B->C(error,应该在此处打印日志) 这样做比较保险，所有error一律采用记录stack 同时采用fail fast

		debug：
			我们为了方便排查错误很多时候会在很多地方使用debug，debug往往很多，上了生产如果开启debvug会导致性能受影响，在上线的时候尽量关闭到debug
		info：
			关键的地方打印一些信息，这些信息数据可以交给大数据进行分析，info量来说相对比较适中。如果你发现了你的info使用量特别大,你就该考虑是不是可以换成debug
		warn(警告):
			warn往往不会导致一个请求失败，但是我们还是应该关注的一些数据，
			比如：服务端页面要求请求1才是第一页，结果客户端传递的是a，这时，我正常返回 但是打印一次warn，如果有大量的warn，这时我们就能知道  应该是一种爬虫行为
		error:
			这就是程序失败，我们的函数没有做好错误兼容，由于业务运行过程中的bug，请求第三方资源，创建数据库记录，这种错误一定要关注
		panic:
			panic会导致整个系统直接挂掉，我们一开始项目启动的时候会链接数据库，可以使用panic去结束掉程序，panic是可以被recover住的
			有一些情况 比如slice越界 2/0，业务中遇到这种panic你的程序挂了 这就要命了

		Fatal:
			最高级别错误，当你使用这个方法的时候你心里应该清楚，这个错误不应该被原谅，就应该导致程序挂掉
	*/

	/*
		写日志的注意事项
			1. 日志中不能记录敏感数据，密码、token等
			2. 日志打印的时候音量写清楚错误的原因 log.Warnf("[getDB] init database:%v",err)
			3. 如果可以，每一条日志尽量和请求的id关联起来
			4. info和error不要乱用，很常见 - 要注意
		实践
			1. 好的日志不可能一开始就设计的很好，这是一个演进的过程，日志打印要重视
			2. 日志不是越多越好，越少越好，关键信息要打印
			3. 日志要兼容本地打印
			4. 能否支持动态调整日志级别（能不能拿到nacos中？）
	*/

}
